Today's matcher keys on (first-segment flight number, departure date).
Codeshares break this: Matrix returns the *marketing* flight number
(e.g. AA6939 JFK→LHR) while PointsPath returns the same physical aircraft
under the *operating* flight number (e.g. BA174, surfaced inside the
American PP query — PP attributes codeshares to the operator).
AA6939 != BA174 → no award attaches, even though one exists.

Live probe (research/probe_pp_matching.py against PP's airline-search):

  American query for JFK→LHR 2026-08-15 returned:
    AA100 18:10  (AA-operated)
    BA174 18:40  (BA-operated, AA-markets it as AA6939)
    BA180 19:10
    AA106 19:20
    BA116 20:20, BA114 21:40, BA182 22:40

Conclusion: PP already surfaces the codeshares — they just hide behind
operating flight numbers. The fix is on our side.

Match strategy is now:

  primary :  (flight#, date)              — unchanged for non-codeshares
  fallback:  (origin, dest, dep_to_minute) — bridges codeshares because both
                                             Matrix and PP read the same
                                             airline-published schedule

Hits from both keys are unioned and deduped by OutboundFlight identity so
non-codeshare flights aren't double-attached.

Minute-precision exact match (no tolerance window) — kept simple to start;
real schedule-source drift between Matrix and PP is rare. If users hit it,
extending to ±N min is a one-line change.

Closes work-22az.

Side notes from the probe (filed for follow-up, not this PR):
- `enableGoogleFlightMatching=true` + a synthetic flight_id hint returned
  zero flights — likely PP needs *real* Google Flights IDs to anchor the
  match. Worth retrying inside work-qmx1 (gflight + PP overlay), where
  fli produces those IDs.
- `BritishAirways` returns "unsupported airline" on this Pro tier.
  Doesn't matter for this fix (codeshares ride in via the operator's
  PP record under whichever airline PP enables them), but worth noting.